home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 6821 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.2 KB
  1. Path: giskard.demon.co.uk!dale
  2. From: dale@giskard.demon.co.uk (Dale Shuttleworth)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: UART 16650
  5. Date: Sun, 3 Mar 1996 00:12:36 GMT
  6. Organization: Dale's home Linux box.
  7. Message-ID: <Dno0L0.MD@giskard.demon.co.uk>
  8. References: <4gf6b3$v5d@mips.pfalz.de> <4gkaj5$i5f@hg.oro.net> <DnAnB1.Mr@giskard.demon.co.uk> <DnMFIn.2Gv@bokonon.ussinc.com>
  9. X-NNTP-Posting-Host: giskard.demon.co.uk
  10. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  11.  
  12. Stephen M. Dunn (stephen@bokonon.ussinc.com) wrote:
  13. : In article <DnAnB1.Mr@giskard.demon.co.uk> dale@giskard.demon.co.uk
  14. :        (Dale Shuttleworth) writes:
  15. : $???  Large receive buffer sizes are primarily there to deal with
  16. : $interrupt latency causing characters to to dropped.  Since it is
  17. : $impossible to drop characters on transmit you don't really need any
  18. : $buffering at all.
  19. : 
  20. :    Large receive buffers can also reduce CPU load.  An interrupt,
  21. : in many cases, is relatively expensive in terms of CPU time (particularly
  22. : in an OS which has to do a context switch in order to run an interrupt
  23. : service routine).  If you can move more than one character during
  24. : that one call to the ISR, you're probably using CPU cycles more
  25. : efficiently as well as reducing the chance of data loss due to
  26. : high latency.
  27.  
  28. :    And yes, you don't _need_ transmit buffers - but that certainly
  29. : doesn't mean they can't be of benefit.
  30.  
  31. I don't disagree that large buffers can reduce CPU load.  The original
  32. post suggested that they improved throughput and my post was largely
  33. intended to respond to that.  I would note however that if the cost
  34. of your large buffer more than insignificant then it is probably more
  35. cost effective to go for a more powerful CPU instead (certianly in the
  36. Intel world).
  37.  
  38. I would also note that the CPU load of serial comms is trivial and if
  39. you are really that concerned, you can probably afford a separate
  40. comms server anyway....
  41.  
  42. : $If you have a really loaded system doing polled transmission then I
  43. : $suppose big transmit buffers are useful, otherwise they're a waste of
  44. : $time.  This is especially true since we usually transmit data to the
  45. : $modem at far higher rates rather than it can actually send it.
  46. : 
  47. :    A really loaded system doing interrupt-drive transmission would
  48. : also benefit, in the same case in which it benefits from
  49. : receive buffers - if the interrupt latency may be so high that
  50. : the interrupt can't be serviced quickly.  Without buffers, the
  51. : system would stop transmitting until such time as the ISR
  52. : can stuff another character into the UART.  If, on the other
  53. : hand, I can load up the UART with a number of characters at once,
  54. : I know they'll all transmit at full speed.
  55.  
  56. If the interrupt cannot be serviced quickly then it doesn't really
  57. matter.  Since we are feeding the modem at well over twice the rate
  58. at which it will transmit the data (under most sensible conditions),
  59. you have to have *really* poor interrupt performance for throughput
  60. to be affected.
  61.  
  62.         Dale.
  63.  
  64. -- 
  65. ******************************************************************************
  66. *  Dale Shuttleworth                                                         *
  67. *  Email: dale@giskard.demon.co.uk                                           *
  68. ******************************************************************************
  69.